[レポート] (CON311) Best practices for deploying microservices on Amazon ECS #reinvent

はじめに

CX事業本部Delivery部の佐藤智樹です。今回はre:Inventでタイトルのセッションに参加した内容をレポートします。

イベント概要

Customers are increasingly running their applications as containerized microservices on Amazon ECS. This chalk talk focuses on sharing best practices for how you can safely and quickly roll out new application versions with Amazon ECS. Consider the various tools you can use for Amazon ECS deployments (e.g., AWS CloudFormation, AWS CDK, Terraform, CLI, and AWS Management Console) and best practices for safeguards you can use depending on the application type (load-balanced vs. event-driven) and infrastructure provider (Amazon EC2 vs. AWS Fargate).

Amazon ECS上でコンテナ化されたマイクロサービスとしてアプリケーションを実行するお客様が増えています。このチョークトークは、Amazon ECSを使用して新しいアプリケーションのバージョンを安全かつ迅速にロールアウトする方法についてのベストプラクティスを共有することに焦点を当てています。Amazon ECSのデプロイに使用できる様々なツール（AWS CloudFormation、AWS CDK、Terraform、CLI、AWS Management Consoleなど）と、アプリケーションタイプ（ロードバランス vs イベントドリブン）やインフラプロバイダー（Amazon EC2 vs AWS Fargate）に応じて使用できるセーフガードのベストプラクティスを検討します。

内容

発表者

Uttara Sridhar氏
Vibhav Agarwal 氏

Agenda

• MicroService: What and Why
• Building Micro Services with Amazon ECS
• Best practice for Amazon ECS deployments
• Continues Deployment
• Safety
• Speed

MicroService: What and Why

最初にECSの立ち位置について紹介後、MicroServiceとはなんだったのかMartin Fowlerの言葉をもとに振り返ります。

MicroServiceは第二の別のアプリケーションを持つ代わりに、独立した複数のサービスを持ち、これらはサービスインタフェースを介して通信します。それらのほとんどはhTTPを介してシームレスに接続され、SQSやKinesisを介しても接続されます。

しかしながら、本当に注目すべきはマイクロサービスは、独立してデプロイ可能で、スケーラブルであるということです。Eコマースのアプリケーションを考えた場合、基本的にはこれらの大きなサービスをすべて格納するようなアーキテクチャになっていると思います。このようなアプリケーション間の緊密な結合は、アプリケーションのスケールアップを不可能にしてしまいます。

さらに重要なのは、これらのアプリケーションをすべてデプロイすることが難しくなることです。例えば、5つの異なるチームがあり、それぞれのサービスを作るために、そのうちの1つのチームがモノリシックアーキテクチャでデプロイしようと考えたとします。彼らはそれを置くと、他のすべてのサービスにまたがる依存関係を作成します。

マイクロサービスに分割することで、それらの4つまたは5のチームのそれぞれが独立して展開することが可能になります。今日の顧客は迅速なサービス提供を期待しています。これはおそらく、マイクロサービスに分解することに時間をかけて成長してきたAmazon Web Servicesでを見ると分かります。

マイクロサービスを展開するのに適した方法は何かというと、おそらく最もわかりやすいのはコンテナでしょう。アプリケーションのすべての依存関係をコンテナという形でカプセル化し、それを独立したマイクロサービスとしてデプロイするのは難しいことではありません。

Building Micro Services with Amazon ECS

Amazon ECSは以下のような要素で構成されます。

ECSのサービスは、Dockerイメージストアのからマイクロサービスを展開するために使用されるもので、自分自身を保護するために使用します。あなたのアプリケーションの要件をカプセル化し、いくつかの追加の要件を持つサービスや技術者を作成することに役立ちます。

ECSによるMicro Serviceのデプロイには以下が使用できます。

以下はアプリケーション自体の変更は発生しないため、デプロイとは定義しません。イメージタグの更新単体では、稼働中のタスクは以前のイメージがキャッシュされるため含んでいません。

デプロイのパターンには以下のようにローリングアップデートやBlue/Greenデプロイがあります。

(佐藤補足:各デプロイの詳細は以下の記事など参考にして下さい)

ECSのデプロイには様々なツールがあります。ECSやMicroServiceに慣れないうちはCDKを使用することをおすすめします。デプロイを早くするためにはCopilotがおすすめです。

ここで以下のアーキテクチャを使ったサービスのデモがありました。

Best practice for Amazon ECS deployments

3つの指標を改めて提示します。

次にAWSでの例を紹介します。Build時点でUnit Testを通過し、Beta→GammaステージでIntegration TestやHealth Checkを実施し、各リージョンの特定のブロックから段階的にデプロイし、アラートが発生した場合はロールバックするよう設定しています。もしうまくいけばリージョン内へ展開、次に他のリージョンへ展開が進みます。

他にはCirkit Breakerを設定することの推奨や、AWSによるECSデプロイ速度の改善の状況やユーザ側でのECSのローリングデプロイの速度を改善する方法が紹介されていました。ローリングアップデートのデプロイ速度改善は、以下のブログの翻訳元ブログの内容だったので、こちらが参考になりそうです。

参考文献には以下が提示されていました。

所感

Session Level-200 なので知っている内容が多かったのですが、AWSでどのようにローリングアップデート(+カナリアリリース)が使われているかの図は初めて見たので、今後の開発のために非常に勉強になりました。そこだけでも見てもらえると参考になるかと思うので是非ご確認ください！